'\" te
.\"  Copyright 1989 AT&T
.\" Copyright (C) 1999, Sun Microsystems,
.\" Inc. All Rights Reserved
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
.TH ROUTING 4P "Nov 9, 1999"
.SH NAME
routing \- system support for packet network routing
.SH DESCRIPTION
.sp
.LP
The network facilities provide general packet routing. The \fBrouting\fR
interface described here can be used to maintain the system's IPv4 routing
table. It has been maintained for compatibility with older applications. The
recommended interface for maintaining the system's routing tables is the
routing socket, described at \fBroute\fR(4P). The routing socket can be used to
manipulate both the IPv4 and IPv6 routing tables of the system. Routing table
maintenance may be implemented in applications processes.
.sp
.LP
A simple set of data structures compose a "routing table" used in selecting the
appropriate network interface when transmitting packets. This table contains a
single entry for each route to a specific network or host. The routing table
was designed to support routing for the Internet Protocol (IP), but its
implementation is protocol independent and thus it may serve other protocols as
well. User programs may manipulate this data base with the aid of two
\fBioctl\fR(2) commands, \fBSIOCADDRT\fR and \fBSIOCDELRT\fR. These commands
allow the addition and deletion of a single routing table entry, respectively.
Routing table manipulations may only be carried out by privileged user.
.sp
.LP
A routing table entry has the following form, as defined in
\fB/usr/include/net/route.h\fR:
.sp
.in +2
.nf
struct rtentry {
        unit_t   rt_hash;               /* to speed lookups */
        struct  sockaddr rt_dst;        /* key */
        struct  sockaddr rt_gateway;    /* value */
        short   rt_flags;               /* up/down?, host/net */
        short   rt_refcnt;              /* # held references */
        unit_t   rt_use;                /* raw # packets forwarded */
/*
 * The kernel does not use this field, and without it the structure is
 * datamodel independent.
 */
#if !defined(_KERNEL)
        struct  ifnet *rt_ifp;          /* the answer: interface to use */
#endif                                  /* !defined(_KERNEL) */
};
.fi
.in -2

.sp
.LP
with \fIrt_flags\fR defined from:
.sp
.in +2
.nf
#define RTF_UP 0x1         /* route usable */
#define RTF_GATEWAY 0x2    /* destination is a gateway */
#define RTF_HOST 0x4       /* host entry (net otherwise) */
.fi
.in -2

.sp
.LP
There are three types of routing table entries: those for a specific host,
those for all hosts on a specific network, and those for any  destination not
matched by entries of the first two types, called a  wildcard route. Each
network interface installs a routing table entry when  it is initialized.
Normally the interface specifies if the route through it is a "direct"
connection to the destination host or network. If the route is direct, the
transport layer of a protocol family usually requests the packet be sent to the
same host specified in the packet. Otherwise, the interface may be requested to
address the packet to an entity different from the eventual recipient;
essentially, the packet is forwarded.
.sp
.LP
Routing table entries installed by a user process may not specify the hash,
reference count, use, or interface fields; these are filled in by the routing
routines. If a route is in use when it is deleted, meaning its \fBrt_refcnt\fR
is non-zero, the resources associated with it will not be reclaimed until all
references to it are removed.
.sp
.LP
User processes read the routing tables through the \fB/dev/ip\fR device.
.sp
.LP
The \fIrt_use\fR field contains the number of packets sent along the route.
This value is used to select among multiple routes to the same destination.
When multiple routes to the same destination exist, the least used route is
selected.
.sp
.LP
A wildcard routing entry is specified with a  \fBzero\fR destination address
value. Wildcard routes are used only when the system fails to find a route to
the destination host and network. The combination of wildcard routes and
routing redirects can provide an economical mechanism for routing traffic.
.SH ERRORS
.sp
.ne 2
.na
\fB\fBEEXIST\fR\fR
.ad
.RS 15n
A request was made to duplicate an existing entry.
.RE

.sp
.ne 2
.na
\fB\fBESRCH\fR\fR
.ad
.RS 15n
A request was made to delete a non-existent entry.
.RE

.sp
.ne 2
.na
\fB\fBENOBUFS\fR\fR
.ad
.RS 15n
Insufficient resources were available to install a new route.
.RE

.sp
.ne 2
.na
\fB\fBENOMEM\fR\fR
.ad
.RS 15n
Insufficient resources were available to install a new route.
.RE

.sp
.ne 2
.na
\fB\fBENETUNREACH\fR\fR
.ad
.RS 15n
The gateway is not directly reachable.  For example, it does not match the
destination/subnet on any of the network interfaces.
.RE

.SH FILES
.sp
.ne 2
.na
\fB\fB/dev/ip\fR\fR
.ad
.RS 11n
\fBIP\fR device driver
.RE

.SH SEE ALSO
.sp
.LP
.BR ioctl (2),
.BR route (4P),
.BR route (8)
